In the realm of computer technology, plug-ins have been key to building customized applications. A minimal kernel provides an application program interface (API) for defining one or more plug-ins that each contains additional functionality. The API nominally provides means for plug-ins to perform various tasks, such as registering with the kernel, transferring data to and from the kernel and/or other plug-ins, and other common undertakings. Once a plug-in has been logically added to the kernel, the unified application now provides altered behavior over and above that of the kernel alone.
Plugs-in are typically employed to add functionality to interactive development environment (IDE) tools for writing software applications, such as Eclipse (see www.eclipse.org). Internet browsers, such as Mozilla Firefox (see www.mozilla.com) and Microsoft Internet Explorer (see www.microsoft.com/windows/ie) also augment their runtimes with additional behavior through plug-ins. Operating systems embrace plug-in device drivers. Other examples of core runtimes (hardware, firmware, and software based) that enable extensibility though plug-ins are abundant.
Browsers and IDE tools are typically single user, single computer applications. In the prior art, plug-ins have not been employed to manage a distributed architecture as taught by the present invention. Traditional operating systems are not distributed, for example where different functions are handled by different cooperating instances.
Distribution of function (objects or services) is well known in the related art. For example, a cohesive distributed system to manage batch jobs may be comprised of submit, schedule, and run functions. In the deployment of such a distributed system, one or more hosts may be configured to perform one or more of these functions. Typically, the requisite software is custom installed or is accessible on each node by means of file sharing. Then at system or application boot time, the host-specific processes are launched, as preconfigured for each host. Thus, on one host one process may be launched for carrying out the submit function, and a second process may be launched to carry out the run function. These different processes may be sharing the same code libraries, but since they are in separate processes they each have their own runtime memory image.
One methodology for managing distributed function is through distributed object technologies, such as the Common Object Request Broker Architecture (CORBA), the Distributed Component Object Model (DCOM), and Remote Method Invocation (RMI). Also known in the related art are web services, which have three main aspects: the web service that processes Extensible Markup Language XML documents; the XML documents that conform to an XML schema, which completely describes valid service requests; and the web service that can be addressed by a requester using one or more protocols such as Transmission Control Protocol (TCP) or Hypertext Transfer Protocol (HTTP). None of these solutions, however, employ coordinated plug-ins to manage a distributed environment.